The many automation-based techniques for implementing and enforcing software license requirements, specifically the permissions, rights and restrictions under which a particular program or software package can be used, have achieved varying degrees of success over the years. Beyond the purely commercial interest of ensuring compensation for access to software, there are additional interests in controlling the concurrent use of defined instances, the available or active feature sets, the restricting of software to particularly identified system hardware or computer platforms, and rights to further distribute software under different categories of licensing. Interest in controlling use is not, however, limited to software vendors. System managers, especially in controlled, secure environments, may wish to actively control and ensure that only specifically licensed software is permitted to be executed or that particular software is executable on particular systems by individuals or groups with necessary permissions.
Conventional automation based licensing strategies include use of self-certifying software modules, other software modules that rely on some inherent system or platform identifier, and dongles and other hardware based add-in components. In each case, a challenge-response transaction is typically implemented to validate the application is licensed for the requested use. Self-certifying software modules typically implement an encryption-based license control algorithm to securely verify a user provided license code against an embedded, encrypted value or transform function uniquely associated with a software package instance. To prevent spoofing circumvention, the license control algorithm can be made additionally reliant on a platform identifier. Conventionally, a platform identifier is a specific processor-resident hardware value or generated as a bit-code representative of the combined identity of platform hardware further tracked against a remote license database.
Alternately, a unique encrypted identifier or encryption transform function, against which a specific software package instance is licensed, can be provided through a proprietary hardware dongle attached to an available system port or, equivalently, an expansion card on a peripheral bus. To reduce the potential for circumvention, a significant portion of the license control algorithm can be implemented on the dongle as part of the transform function. Conventionally, a software package reliant on a hardware dangle is constructed to frequently require access to and validation of continued operation from the dongle, rendering impractical circumvention by selectively nullifying all code points within the software package that rely on dongle access.
These conventional licensing strategies become particularly complicated, if not rendered fundamentally impractical, where the computer system platform used to execute the licensed software is implemented using virtual machine technologies. Virtualization decouples the application software from the underlying hardware platform. Consequently, the license control algorithms implemented by application programs cannot discern changes in the underlying hardware platform, allowing the application program, including virtual computer environment, to be copied and executed without imposed limit. Decoupling also defeats the ability of the application program to discern whether a hardware dongle is uniquely available to just one application instance or, through virtual connections, shared by many.
Aside from the licensing issues, however, the benefits of virtual machines for the execution of conventional software applications are compelling and well recognized. Virtual machine technology enables multiple, relatively independent virtual machines to be executed on a single host platform. Each virtual machine encapsulates a guest operating system that, as between different virtual machine instances, may be of different type and revision. Each guest operating system, in turn, manages a discrete application execution space. Virtual machine technology thus enables more efficient use of hardware capacity, while still ensuring that the users of the different virtual machines have access and use of a “complete” computer. Depending on specific implementation, virtualization can and typically does ensure security as between the applications executed in different virtual machines even as executed on the same physical machine. The virtualization of the underlying computer system isolates potentially unstable or unsafe software from adversely affecting the hardware state or system files required for running the physical (as opposed to virtual) hardware.
As is well known in the field of computer science, a virtual machine (VM) is an abstraction—“virtualization”—of an actual physical computer system. FIG. 1 shows one possible arrangement of a computer system 10 that implements virtualization. One or more virtual machines (VMs) or “guests” 12, 12N are installed on a “host platform,” or simply “host,” which will include system hardware 14, also referred to herein as a hardware platform, and virtualization software 15. Virtualization software 15 may comprise one or more layers or co-resident components comprising system-level software, such as a kernel 16, and a virtual machine monitor 18, 18N, or some combination of these. The system hardware 14 typically includes one or more processors 20, memory 22, some form of mass storage 24, and various other devices 26. The configuration of virtualization software shown in FIG. 1 is referred to as an “unhosted” virtualization system because the kernel 16 takes the place of a host operating system. Virtualization software could also provide a hosted configuration in which a host operating system (not shown) is co-resident with a hypervisor or virtual machine monitor.
Each VM 12 will typically have both virtual system hardware 28 and guest system software 30. The virtual system hardware typically includes at least one virtual CPU 32, virtual memory 34, at least one virtual disk 36, and one or more virtual devices 38. Note that a disk—virtual or physical—is also a “device,” but is usually considered separately because of the important role of the disk. All of the virtual hardware components of the VM may be implemented by virtualization software 15 using known techniques to emulate the corresponding physical components. Thus, the virtual system hardware 28 does not exist as software or hardware components within virtual machine 12, however, the states of these virtual devices are generally considered to be part of virtual machine 12. Furthermore, virtual system hardware 28, illustrated as being “within” virtual machine 12, provides a convenient representation of the execution environment of guest system software 30. Guest system software 30 includes a guest operating system (OS) 40 and drivers 42 as needed for the various virtual devices 38. Guest system software 30 generally will include applications (not shown) that execute in an application execution environment provided by guest OS 40 and virtual system hardware 28.
Note that a single VM may be configured with more than one virtualized processor. To permit computer systems to scale to larger numbers of concurrent threads, systems with multiple CPUs have been developed. These symmetric multi-processor (SMP) systems are available as extensions of the PC platform and from other vendors. Essentially, an SMP system is a hardware platform that connects multiple processors to a shared main memory and shared I/O devices. Virtual machines may also be configured as SMP VMs. FIG. 1, for example, illustrates multiple virtual processors 320-M (VCPU0, VCPU1, . . . , VCPUm) within the VM 200.
Yet another configuration is found in a so-called “multi-core” architecture, in which more than one physical CPU is fabricated on a single chip, with its own set of functional units (such as a floating-point unit and an arithmetic/logic unit ALU), and can execute threads independently; multi-core processors typically share only very limited resources, such as some cache. Still another technique that provides for simultaneous execution of multiple threads is referred to as “simultaneous multi-threading,” in which more than one logical CPU (hardware thread) operates simultaneously on a single chip, but in which the logical CPUs flexibly share some resource such as caches, buffers, functional units, etc. The terms, “CPU” or “processor” as used herein, should be understood to encompass any of these processor configurations.
If VM 12 is properly designed, applications 44 running on the VM will function as they would if run on a “real” computer, even though the applications are running at least partially indirectly, that is via the guest OS 42 and virtual processor(s). Executable files will be accessed by the guest OS from the virtual disk 36 or virtual memory 34, which will be mapped to portions of physical disk 24 or memory 22 that are allocated to that VM. Once an application is installed within the VM, the guest OS retrieves files from the virtual disk just as if the files had been pre-stored as the result of a conventional installation of the application. The design and operation of virtual machines are well known in the field of computer science.
As mentioned above, virtualization software 15 is an interface that is logically interposed between guest system software 30 within VM 12 and the various hardware components and devices in the underlying hardware platform. The term, “hypervisor” is often used to describe both a VMM 18 and a kernel 16 together, either as separate but cooperating components or with one or more VMMs incorporated wholly or partially into the kernel itself. However, “hypervisor” is sometimes used instead to mean some variant of a VMM alone, which interfaces with some other software layer(s) or component(s) to support the virtualization. In some systems, some virtualization code is included in at least one “superior” VM to facilitate the operations of other VMs. Furthermore, specific software support for VMs may be included in the host OS itself.
Certain software components illustrated are shown and described as being within a virtualization software 15 located logically between virtual machines 12 and the system hardware 14. However, it is possible to implement at least part of virtualization software 15 within specialized hardware (not shown). Therefore, the illustrated embodiments are given only for the sake of simplicity and clarity and by way of illustration—as mentioned above, the distinctions between various components of a virtualized platform are not always so clear-cut. Unless otherwise indicated, the terms, “virtual,” “virtualize,” “virtualization,” etc., refer herein to virtualized computer systems having any type or configuration of virtualization software.
The various virtualized hardware components in the VM, such as virtual CPU(s) 32, virtual memory 34, virtual disk 36, and virtual device(s) 38, are shown as being part of the VM 12 for the sake of conceptual simplicity. In actuality, these “components” are usually implemented as software emulations 46 included in the VMMs 181-N. One advantage of such an arrangement is that the VMM may (but need not) be set up to expose “generic” devices, which facilitate VM migration and hardware platform-independence.
The availability of virtualization software has posed challenges to developers concerned about piracy of their products. In particular, a self-certifying module will be unable to distinguish unique virtualized platform instances, at least not without substantial additional, and typically complex, virtualization platform specific coding. Conversely, where a unique platform instance can be discerned, the characterizing platform details are represented by the virtualized rather than underlying physical platform. Therefore, self-certifying modules may certify in all copies of the virtual machine.
Virtualization can also limit the effective use of hardware dongles. In effect, all virtual machines implemented on host platform may nominally have unconstrained access to a particular dongle, thereby allowing application instances to run equally licensed in each of the hosted virtual machines. The different virtual machines can, of course, be distinctly configured to define which have access to a particular port and, thereby, an attached dongle. Beyond the potential for circumvention of copy protections schemes by system administrator modification of the configuration files, the specific restriction of licensed virtual machines to a particular hardware dongle significantly constrains other intrinsic benefits of virtualization. For example, virtualization enables ready movement of virtual machines to different platforms to provide automated load scaling and redundancy in case of physical hardware failures. Constraint to a particular hardware platform due to a physical dongle requirement is undesirable, particularly where direct manual management intervention is intrinsically required to preserve the scaling and redundancy capabilities of virtualization.